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Systems and Methods for Managing Drivers in a Computing System 

Field of the Invention: 

The present invention relates to systems and methods for managing drivers in a 
5 computing system. 

Background of the Invention: 

In the context of computer system design, drivers are software components that expose 
hardware capabilities to the operating system, so that the operating system may in turn expose those 

1 0 capabilities to applications. Typically the operating system interacts with a driver through a Device 
Driver Interface ("DDI"), a carefully defined protocol that enables the operating system to load the 

;3 driver, inquire about the capabilities provided by the hardware, and make those capabihties available 

7| to applications. 

;2 The software interfiaces provided to applications by the operating system are known as 

7a 5 Application Programming Interfaces ("APIs"). The APIs provided by the operatmg system provide 
' ' applications with software abstractions that may or may not closely resemble the characteristics of 
f the underlying hardware. An example of a dramatic departure from the underlying hardware is the 
13 directory/file software abstraction provided for mass storage. Another software abstraction that does 
Si not resemble the underlying hardware is virtual memory, which enables apphcations to transparently 

IKS!' 

^0 use local hard disk storage as though it were random access memory. 

When APIs cause hardware resources to be utilized, the operating system calls the driver 
through the DDI to make use of those resources. Due to the differences between the software 
abstractions provided by APIs and the underlying hardware, this translation from API calls to DDI 
calls can entail significant amounts of logic and code. In the context of this specification, the 
25 software between the application-level API and the driver-level DDI is known collectively as the 
"runtime." 

Application, drivers, etc. are generally written in a high-level lanugage such as C. Such 
languages have typically been implemented primarily by compilation to native code. In such 
cases, drivers are written separately from the application and other programs that operate on a 
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system. The application and drivers are then typically linked together either during an 
installation process or dynamically (e.g., DLL) when the application is executed. The advantage 
of such a system is that the compiler can be designed to optimize the code for a particular class of 
processor (e.g X86). However, tiie compiler may not optimize the code for a particular 
microprocessor, e.g., PENTIUM IV versus PENTIUM m. Moreover the compiler does not 
optimize the code for other system parameters including driver versions and other hardware 
components or take into account the particular system constraints of the target system, histead, 
the appUcation or runtime level system must employ computationally expensive logic to 
determine such parameters and processor constraints so that the program can be compiled to 
execute on an entire class of computer systems. 

Another common programming paradigm is to compile code at runtime. A just-in-time 
(JIT) compiler is an example of such as system. Other systems that compile at runtime include 
continuous compilation systems that immediately begin execution in an interpretive state but 
compile the code over time and continously optimize the compilation. With just-in-time 
compilers, as classes are loaded into the virtual machine, the method pointers m the virtual 
method table are replaced with pointers to the JTT compiler. Then, the first time each method is 
called, the JIT compiler is invoked to compile the method. The pointer in the virtual method 
table is then patched to point to the native-code version of the method so that future calls to the 
method will jump to the native-code. These JIT compiler systems have the advantage of 
trasmitting code to a target machine in an intermediate langauge (IL) such as JAVA bytecodes, 
CLRT instructions, and so on. The compiler is designed to convert the EL into instructions 
executable by the native processor. As a result, the same IL instructions can be sent to 
computers having different native processors and execute nonetheless on the target processor. 

Although such intemediate language compilers compile the intermediate language 
instructions on the target computer system, they also do not optimize the code for a particular 
target computer system, including accounting for driver versions and other hardware components 
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Summary of the Invention: 

In view of the foregoing, the present invention provides managed code comprising 
applications and runtime, and/or driver. The managed code is compiled by a compiler that has a 
priori knowledge of the target computer system's exact hardware configuration, just as the JIT 
5 compiler has a priori knowledge of the microprocessor type on the client. At compile time, the 
system's effective version of various hardware drivers are known, so if an application and driver are 
managed, the compiler can emit an executable tuned for a particular driver version. 

Accordingly, the invention comprises system and method that manage code to compile 
code configured for an operating system having a selected processor and a driver that interacts 
1 0 with a computing component. The system comprises a plurality of application instructions that 

are received in an intermediate language readable by an intermediate language compiler and a 
13 plurality of runtime instructions that are also received in an intermediate language readable by an 
iTl intermediate language compiler. An intermediate language compiler compiles the application ► 

instructions and the runtime instructions into a set of managed code instructions executable by 
Id 5 the processor for interacting with the selected driver. The driver (or a portion of the driver) may 
^ ' also be provided in the intermediate language and compiled along with the application 
H instructions and the runtime instructions into a set of managed code instructions. 

□ Brief Description of the Drawings: 

' ^0 The system and methods for managing code are further described with reference to the 

accompanying drawings in which: 

Figure 1 is a block diagram representing an exemplary network environment having a 
variety of computing devices in which the present invention may be implemented; 

Figure 2 is a block diagram representing an exemplary nonlimiting computing device in 
25 which the present invention may be implemented; 

Figure 3 A and 3B illustrate different driver models for various computing systems; 

Figure 4 is a block diagram of a computer system having a user-mode driver DLL 
architecture in accordance with an aspect of the invention; 

Figure 5 illustrates the sequence of events that occur when an application making API 
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calls in an example graphics application; 

Figure 6 illustrates the application of JIT compilation to application and runtime in 
accordance with an aspect of the invention; and 

Figure 7 illustrates the application of JIT compilation to application, driver and runtime in 
5 accordance with an aspect of the invention. 

Detailed Description of the Invention: 

Overview 

Proponents of online driver models cite performance advantages as the principal motivation 
1 0 for merging the API implementation into the driver. This merge has many undesirable side effects, 

mainly due to the inability of subsequent releases of the Runtime to add features, performance 
Q improvements, or changes of API policy on top of drivers that predated the release of the Runtime, 
; r^; The invention described herein recognizes that managed code, including applications, runtime, and 
£ driver, should have a priori knowledge of the client's exact hardware configuration, just as the JIT 
Ul 5 compiler has a priori knowledge of the microprocessor type on the cUent. For example, at JTT time, 

the system knows the effective version of the graphics driver (DirectX 6.0, DirectX 7.0, and so on), 
H so if the application and driver are managed, the JIT compiler can emit an executable tuned for a 
C3 particular driver version. 

^^^0 Exemplarv Networked and Distributed Environments 

One of ordinary skill in the art can appreciate that a computer or other client or server 
device can be deployed as part of a computer network, or in a distributed computing 
environment. In this regard, the present invention pertains to any computer system having any 
number of memory or storage units, and any number of applications and processes occurring 
25 across any number of storage units or volumes. The present invention may apply to an 

environment with server computers and client computers deployed in a network environment or 
distributed computing environment, having remote or local storage. The present invention may 
also be applied to standalone computing devices, having programming language functionality, 
interpretation and execution capabilities for generating, receiving and transmitting information in 
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connection with services. 

Distributed computing facilitates sharing of computer resources and services by direct 
exchange between computing devices and systems. These resources and services include the 
exchange of information, cache storage, and disk storage for files. Distributed computing takes 
5 advantage of network connectivity, allowing clients to leverage their collective power to benefit 
the entire enterprise. In this regard, a variety of devices may have data sets for which it would be 
desirable to perform the image boundary definition techniques of the present invention. 

Figure 1 provides a schematic diagram of an exemplary networked or distributed 
computing environment. The distributed computing environment comprises computing objects 
10 10a, 10b, etc. and computing objects or devices 1 10a, 1 10b, 1 10c, etc. These objects may 

comprise programs, methods, data stores, programmable logic, etc. The objects may comprise 
C3 portions of the same or different devices such as PDAs, televisions, MPS players, televisions, 
T! personal computers, etc. Each object can communicate with another object by way of the 
^ communications network 14. This network may itself comprise other computing objects and 

•kttS 

Wl 5 computing devices that provide services to the system of Figure 1 . In accordance with an aspect 

m 

^" " of the invention, each object 10 or 1 10 may contain data for which it would be desirable to 

perform image cut-out or boundary definition. It may also be desirable to compare an image cut- 
Q out fi*om one object 10 or 1 10 with an image cut-out of another object 10 or 1 10. 

In a distributed computing architecture, computers, which may have traditionally been 
• ^'20 used solely as clients, commimicate directly among themselves and can act as both clients and 
servers, assuming whatever role is most efficient for the network. This reduces the load on 
servers and allows all of the clients to access resources available on other clients, thereby 
increasing the capabihty and efficiency of the entire network. 

Distributed computing can help businesses deliver services and capabilities more 
25 efficiently across diverse geographic boundaries. Moreover, distributed computing can move data 
closer to the point where data is consumed acting as a network caching mechanism. Distributed 
computing also allows computing networks to dynamically work together using intelligent 
agents. Agents reside on peer computers and communicate various kinds of information back and 
forth. Agents may also initiate tasks on behalf of other peer systems. For instance, intelligent 
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agents can be used to prioritize tasks on a network, change traffic flow, search for files locally or 
determine anomalous behavior such as a virus and stop it before it affects the network. All sorts 
of other services may be contemplated as well. The image cut-out algorithm(s) of the present 
invention may be implemented in such an environment. 

It can also be appreciated that an object, such as 1 10c, may be hosted on another 
computing device 10 or 1 10. Thus, although the physical environment depicted may show the 
connected devices as computers, such illustration is merely exemplary and the physical 
environment may ahematively be depicted or described comprising various digital devices such 
as PDAs, televisions, MP3 players, etc., software objects such as interfaces, COM objects and 
the like. 

There are a variety of systems, components, and network configurations that support 
distributed computing environments. For example, computing systems may be connected 
together by wireUne or wireless systems, by local networks or widely distributed networks. 
Currently, many of the networks are coupled to the Intemet, which provides the infi^astructure for 
widely distributed computing and encompasses many different networks. 

The Intemet commonly refers to the collection of networks and gateways that utilize the 
TCP/IP suite of protocols, which are well-known in the art of computer networking. TCP/IP is an 
acronym for "Transport Control Protocol/Interface Program." The Intemet can be described as a 
system of geographically distributed remote computer networks interconnected by computers 
executing networking protocols that allow users to interact and share information over the 
networks. Because of such wide-spread information sharing, remote networks such as the 
Intemet have thus far generally evolved into an open system for which developers can design 
software applications for performing specialized operations or services, essentially without 
restriction. 

Thus, the network infirastructure enables a host of network topologies such as 
client/server, peer-to-peer, or hybrid architectures. The "client" is a member of a class or group 
that uses the services of another class or group to which it is not related. Thus, in computing, a 
client is a process, i.e., roughly a set of instructions or tasks, that requests a service provided by 
another program. The client process utilizes the requested service without having to "know" any 
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working details about the other program or the service itself. In a client/server architecture, 
particularly a networked system, a client is usually a computer that accesses shared network 
resources provided by another computer e.g,, a server. In the example of Figure 1, computers 
11 Oa, 11 Ob, etc. can be thought of as cUents and computer 1 Oa, 1 Ob, etc. can be thought of as the 
server where server lOa, lOb, etc. maintains the data that is then replicated in the cUent 
computers llOa, 11 Ob, etc. 

A server is typically a remote computer system accessible over a remote network such as 
the Intemet. The cUent process may be active in a first computer system, and the server process 
may be active in a second computer system, communicating with one another over a 
communications medium, thus providing distributed functionality and allowing multiple cUents 
to take advantage of the information-gathering capabilities of the server. 

Client and server communicate with one another utilizing the functionality provided by a 
protocol layer. For example, Hypertext-Transfer Protocol (HTTP) is a common protocol that is ► 
used in conjunction with the World Wide Web (WWW) or, simply, the "Web." Typically, a 
computer network address such as a Universal Resource Locator (URL) or an Intemet Protocol 
(IP) address is used to identify the server or client computers to each other. The network address 
can be referred to as a Universal Resource Locator address. For example, communication can be 
provided over a communications medium. In particular, the client and server may be coupled to 
one another via TCP/IP connections for high-capacity communication. 

Thus, Figure 1 illustrates an exemplary networked or distributed environment, with a 
server in communication with client computers via a network/bus, in which the present invention 
may be employed. In more detail, a number of servers lOa, lOb, etc., are interconnected via a 
communications network/bus 14, which may be a LAN, WAN, intranet, the Intemet, etc., with a 
number of cHent or remote computing devices 1 lOa, 1 lOb, 1 lOc, 1 lOd, 1 lOe, etc., such as a 
portable computer, handheld computer, thin client, networked appliance, or other device, such as 
a VCR, TV, oven, light, heater and the like in accordance with the present invention. It is thus 
contemplated that the present invention may apply to any computing device in connection with 
which it is desirable to commimicate to another computing device with respect to image cut-out 
or boundary definition services. 



MSFT-0740/1 77740. 1 8 PATENT 

In a network environment in which the communications network^bus 14 is the Internet, 
for example, the servers 10 can be Web servers with which the clients UOa, 1 10b, 1 10c, 1 lOd, 
1 lOe, etc. communicate via any of a number of known protocols such as hypertext transfer 
protocol (HTTP). Servers 10 may also serve as clients 1 10, as may be characteristic of a 
5 distributed computing enviroimient. Communications may be wired or wireless, where 

appropriate. Client devices 1 10 may or may not communicate via communications network/bus 
14, and may have independent communications associated therewith. For example, in the case of 
a TV or VCR, there may or may not be a networked aspect to the control thereof. Each client 
computer 110 and server computer 10 may be equipped with various application program 
10 modules or objects 135 and with connections or access to various types of storage elements or 
objects, across which files may be stored or to which portion(s) of files may be downloaded or 
C3 migrated. Any computer 10a, 10b, 1 10a, 1 10b, etc. may be responsible for the maintenance and 
M updating of a database 20 or other storage element in accordance with the present invention, such 
^ as a database 20 for storing image processing software for processing images in accordance with 

M 5 the present invention. Thus, the present invention can be utilized in a computer network 

W 

! ' environment having client computers 1 1 Oa, 1 1 Ob, etc. that can access and interact with a 

:f=f computer network/bus 14 and server computers 10a, 10b, etc. that may interact with client 

C3 computers 1 10a, 1 10b, etc. and other devices 111 and databases 20. 

s 

|?is ii 

'^0 Exemplary Computing Device 

Figure 2 and the following discussion are intended to provide a brief general description 
of a suitable computing environment in which the invention may be implemented. It should be 
understood, however, that handheld, portable and other computing devices and computing 
objects of all kinds are contemplated for use in connection with the present invention. While a 
25 general purpose computer is described below, this is but one example, and the present invention 
may be implemented with a thin client having network/bus interoperability and interaction. 
Thus, the present invention may be implemented in an environment of networked hosted services 
in which very little or minimal client resources are implicated, e.g., a networked environment in 
which the client device serves merely as an interface to the network/bus, such as an object placed 
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in an appliance. In essence, anywhere that data may be stored or from which data may be 
retrieved is a desirable, or suitable, environment for operation of the image cut-out algorithm(s) 
of the invention. 

Although not required, the invention can be implemented via an operating system, for use 
5 by a developer of services for a device or object, and/or included within application software that 
aids in processing image data. Software may be described in the general context of 
computer-executable instructions, such as program modules, being executed by one or more 
computers, such as cUent workstations, servers or other devices. Generally, program modules 
include routines, programs, objects, components, data structures and the like that perform 
10 particular tasks or implement particular abstract data types. Typically, the fimctionality of the 

program modules may be combined or distributed as desired in various embodiments. Moreover, 
Q those skilled in the art will appreciate that the invention may be practiced with other computer 

j;ss:. 

1 system configurations. Other well known computing systems, environments, and/or 
V3 configurations that may be suitable for use with the invention include, but are not limited to, 
id 5 personal computers (PCs), automated teller machines, server computers, hand-held or laptop 
devices, multi-processor systems, microprocessor-based systems, programmable consumer 
electronics, network PCs, appliances, Hghts, environmental control elements, minicomputers, 
Q mainfirame computers and the like. The invention may also be practiced in distributed computing 
S environments where tasks are performed by remote processing devices that are linked through a 
- 420 communications networklDUS or other data transmission medixun. In a distributed computing 

environment, program modules may be located in both local and remote computer storage media 
including memory storage devices, and client nodes may in tum behave as server nodes. 

Figure 2 thus illustrates an example of a suitable computing system environment 100 in 
which the invention may be implemented, although as made clear above, the computing system 
25 environment 100 is only one example of a suitable computing environment and is not intended to 
suggest any limitation as to the scope of use or functionality of the invention. Neither should the 
computing environment 100 be interpreted as having any dependency or requirement relating to 
any one or combination of components illustrated in the exemplary operating environment 100. 
With reference to Figure 2, an exemplary system for implementing the invention includes 
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a general purpose computing device in the form of a computer 1 10. Components of computer 
110 may include, but are not limited to, a processing unit 120, a system memory 130, and a 
system bus 121 that couples various system components including the system memory to the 
processing unit 120. The system bus 121 may be any of several types of bus structures including 
5 a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of 
bus architectures. By way of example, and not limitation, such architectures include Industry 
Standard Architecture (ISA) bus. Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) 
bus. Video Electronics Standards Association (VESA) local bus, and Peripheral Component 
Interconnect (PCI) bus (also known as Mezzanine bus). 
10 Computer 1 10 typically includes a variety of computer readable media. Computer 

readable media can be any available media that can be accessed by computer 110 and includes 
rt both volatile and nonvolatile media, removable and non-removable media. By way of example, 
; and not limitation, computer readable media may comprise computer storage media and 
^ communication media. Computer storage media includes both volatile and nonvolatile, 
I yi 5 removable and non-removable media implemented in any method or technology for storage of 
' information such as computer readable instructions, data structures, program modules or other 
p data. Computer storage media inchides, but is not limited to, RAM, ROM, EEPROM, flash 
C3 memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical 
i disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage 
^^^20 devices, or any other medium which can be used to store the desired information and which can 
accessed by computer 110. Communication media typically embodies computer readable 
instructions, data structxires, program modules or other data in a modulated data signal such as a 
carrier wave or other transport mechanism and includes any information delivery media. The 
term "modulated data signal" means a signal that has one or more of its characteristics set or 
25 changed in such a manner as to encode information in the signal. By way of example, and not 
limitation, communication media includes v^red media such as a wired network or direct-wired 
connection, and wireless media such as acoustic, RF, infrared and other wireless media. 
Combinations of any of the above should also be included within the scope of computer readable 
media. 
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The system memory 130 includes computer storage media in the form of volatile and/or 
nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 
132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer 
information between elements within computer 1 10, such as during start-up, is typically stored in 
ROM 131. RAM 132 typically contains data and/or program modules that are inmiediately 
accessible to and/or presently being operated on by processing unit 120. By way of example, and 
not limitation, Figure 2 illustrates operating system 134, appUcation programs 135, other 
program modules 136, and program data 137. 

The computer 110 may also include other removable/non-removable, volatile/nonvolatile 
computer storage media. By way of example only, Figure 2 illustrates a hard disk drive 141 that 
reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 
that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 
155 that reads from or writes to a removable, nonvolatile optical disk 156, such as a CD ROM or* 
other optical media. Other removable/non-removable, volatile/nonvolatile computer storage 
media that can be used in the exemplary operating environment include, but are not limited to, 
magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, sohd state 
RAM, solid state ROM, and the hke. The hard disk drive 141 is typically connected to the 
system bus 121 through an non-removable memory interface such as interface 140, and magnetic 
disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a 
removable memory interface, such as interface 150. 

The drives and their associated computer storage media discussed above and illustrated in 
Figure 2 provide storage of computer readable instructions, data structures, program modules and 
other data for the computer 1 10. In Figure 2, for example, hard disk drive 141 is illustrated as 
storing operating system 144, apphcation programs 145, other program modules 146, and 
program data 147. Note that these components can either be the same as or different from 
operating system 134, application programs 135, other program modules 136, and program data 
137. Operating system 144, application programs 145, other program modules 146, and program 
data 147 are given different numbers here to illustrate that, at a minimum, they are different 
copies. A user may enter commands and information into the computer 110 through input 
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devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, 
trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, 
game pad, satellite dish, scanner, or the like. These and other input devices are often connected 
to the processing unit 120 through a user input interface 160 that is coupled to the system bus 
5 121, but may be connected by other interface and bus structures, such as a parallel port, game 
port or a universal serial bus (USB). A graphics interface 182, such as Northbridge, may also be 
connected to the system bus 121. Northbridge is a chipset that communicates with the CPU, or 
host processing unit 120, and assumes responsibility for AGP communications. One or more 
graphics processing units (GPUs) 184 may communicate with graphics interface 182. In this 
10 regard, GPUs 184 generally include on-chip memory storage, such as register storage and GPUs 
184 communicate with a video memory 186. A monitor 191 or other type of display device is 
Q also connected to the system bus 121 via an interface, such as a video interface 190, which may 
: in turn communicate with video memory 1 86. In addition to monitor 191, computers may also * 
^5 include other peripheral output devices such as speakers 197 and printer 196, which may be 
yi 5 connected through an output peripheral interface 195. 

:: ilss: 

' The computer 1 1 0 may operate in a networked or distributed environment using logical 

if'f connections to one or more remote computers, such as a remote computer 180. The remote 
£3 computer 1 80 may be a personal computer, a server, a router, a network PC, a peer device or 
S other common network node, and typically includes many or all of the elements described above 
^^20 relative to the computer 110, although only a memory storage device 181 has been illustrated in 
Figure 2. The logical connections depicted in Figure 2 include a local area network (LAN) 171 
and a wide area network (WAN) 173, but may also include other networks/buses. Such 
networking environments are commonplace in homes, offices, enterprise-wide computer 
networks, intranets and the Internet. 
25 When used in a LAN networking environment, the computer 1 10 is connected to the 

LAN 171 through a network interface or adapter 170. When used in a WAN networking 
environment, the computer 110 typically includes a modem 172 or other means for establishing 
communications over the WAN 173, such as the Intemet. The modem 172, which may be 
internal or external, may be connected to the system bus 121 via the user input interface 160, or 
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other appropriate mechanism. In a networked environment, program modules depicted relative 
to the computer 1 10, or portions thereof, may be stored in the remote memory storage device. By 
v^ay of example, and not hmitation, Figxire 2 illustrates remote application programs 185 as 
residing on memory device 181. It will be appreciated that the network connections shown are 
5 exemplary and other means of establishing a communications link between the computers may 
be used. 

Exemplary Distributed Computing Frameworks or Architectures 

Various distributed computing frameworks have been and are being developed in Ught of 
10 the convergence of personal computing and the Internet. Individuals and business users alike are 
provided with a seamlessly interoperable and Web-enabled interface for applications and 
□ computing devices, making computing activities increasingly Web browser or network-oriented. 
"1 For example, MICROSOFT®'s .Net platform includes servers, building-block services, ► 

such as Web-based data storage and dovraloadable device software. Generally speaking, the .Net 

bl 5 platform provides (1) the ability to make the entire range of computing devices work together 

In 

" ' and to have user information automatically updated and synchronized on all of them, (2) 

P increased interactive capability for Web sites, enabled by greater use of XML rather than HTML, 

C3 (3) online services that feature customized access and delivery of products and services to the 

sr. 

user from a central starting point for the management of various apphcations, such as e-mail, for 
nio example, or software, such as Office .Net, (4) centralized data storage, which will increase 

efficiency and ease of access to information, as well as synchronization of information among 
users and devices, (5) the ability to integrate various communications media, such as e-mail, 
faxes, and telephones, (6) for developers, the ability to create reusable modules, thereby 
increasing productivity and reducing the number of programming errors and (7) many other 
25 cross-platform integration features as well. 

Management of Drivers in a Computing System 

Figures 3A and 3B is a simple depiction of how an appUcation program 135, runtime 302, 
and driver 303 interact through an API and DDL 
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In the context of graphics API/DDI deployment, currently there are two prevalent driver 
models: an online driver model and a layered driver model Figure 3 A depicts an online driver, 
essentially a full API implementation that has been instrumented to run on a particular piece of 
hardware e.g., video interface 190 (Figure 2). Examples of APIs that utihze online driver models 
5 include proprietary graphics APIs such as 3Dfic Glide and ATI GIF, as well as OpenGL. 

Layered drivers, as depicted in Figure 3B, introduce an additional level of indirection in 
which the API implementation implements some logic (such as parameter vaUdation) and code (such 
as the geometry pipeline) before calling driver 303 through the DDL The term 'layered driver' refers 
not only to the idea that the API calls the DDI after doing work, but also to the idea that driver 303 
10 can implement different 'layers' depending on how much functionality is implemented by hardware 
306. For example, the DDI for a graphics hardware product that implemented rasterization only 
{3 would be lower-level than for a product that implemented transform and Hghting as well as 
?n rasterization. 

^ Supporting a variety of layered drivers increases the complexity of a runtime's 302 

id 5 implementation. For example, DIRECTX 7.0 from MICROSOFT, which has support for 
'I ' hardware-accelerated transform and lighting, must check whether the imderlying driver 303 
^ implements that featxire. If so, applications 135 can create and use devices with the feature; 
C3 otherwise, the feature must be emulated by runtime 302 in software. As a result, the code paths 
f =1 executed by DIRECTX 7.0 are significantly different depending on whether it is running on a 
^S) DIRECTX 7.0-style driver or a pre-DIRECTX 7.0 driver. 

Figure 4 further illustrates the layers of an example application, runtime, and driver in a 
system. The Application 135, Rimtime 302, and part of the Driver 303 operate in user mode to 
write drawing commands into hardware-specific command buffers in DMA memory. In a 
contemporary PC system, these writes would typically be non-temporal writes into AGP memory; 
25 and as depicted in this implementation example. Application 135 resides in an EXE and Runtime 
302 and User Mode Driver 303 reside in DLLs that are dynamically linked into Application 135. 
These details of the user mode portion of the system can vary; specifically, the Application 135, 
AppUcation 135 and Runtime 302, or Application 301, Runtime 302 and User Mode Driver 303 
could potentially be managed code. 
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To defend against unauthorized replacement of a User Mode Driver (e.g., 303), a system 
typically queries the Kernel Driver 405 (since kernel code is trusted from a security standpoint) for 
User Mode Driver 303 DLL to load. 

Command Buffer Scheduler 404 ("Scheduler") and Kemel Driver 405 work together in 
kernel mode to dispatch command buffers to Hardware 406 (Scheduler 404 decides which command 
buffer should be dispatched, while Kemel Driver 405 instructs Hardware 406 to dispatch a command 
buffer at the request of Scheduler 404). This system contemplates that the bulk of the driver logic 
would reside in User Mode Driver 403 DLL, not Kemel Driver 405. While User Mode Driver 403 
can contain large amounts of code that maps DDI-level calls into hardware-specific commands 
(which operation can be complicated and error-prone, especially when compiling a vertex and/or 
shader program), Kemel Driver 405 is comparatively small and simple, maximizing system 
robustness. 

Figure 5 clarifies the sequence of events that occur when an Application 135 is making API 
calls in an example of graphics operations. The command buffers are not specifically depicted in 
Figure 5 as a hardware component; per Figure 4, the User Mode Driver 303 writes hardware-specific 
commands into the device's current command buffer, the Command Buffer Scheduler (part of the 
System Kemel Support 530) dispatches the command buffer to the hardware 306 via the Kemel 
Mode Driver 405, and finished command buffers are recycled for use by an Application 1 35 in the 
system. Note that multiple AppUcations 135 can potentially share the pool of available command 
buffers, with the System Kemel Support 530 arbitrating sharing of that resource. 

When Application 135 initially creates a drawing context 501, the System Kemel Support 
530 checks to see whether a new conmiand buffer can be created 53 1 . If so, the new command buffer 
is created 532 and initialized 533, and the thread obtains an initialized command buffer 534 before 
the Application 135 can perform drawing calls 502. If a command buffer could not be created in step 
531, Application 135 must wait until an Initialized command buffer becomes available 534. Once 
Application 135 has obtained a command buffer. Application 135, Runtime 302 and User Mode 
Driver 303 enter the typical interaction between the three components that cause hardware-specific 
commands to be written into the conmiand buffer. The Drawing calls 502 from Application 135 are 
validated 5 11 by Runtime 302; a check 512 then determines whether a flush of the current command 
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buffer is needed. If not, the drawing command is translated to a simpler, canonical DDI call 513 and 
passed to User Mode Driver 520. The driver translates the DDI call into hardware specific 
commands and attempts to write them into the command buffer. If the check 522 for flush 
determines that there is no room in the command buffer, the command buffer must be submitted to 
5 System Kernel Support 530 and a new command buffer obtained from same before command can be 
written and execution can continue. If either Runtime 302 or User Mode Driver 303 determines that 
a flush is needed, per step 535 the command buffer is added to the Waiting queue. At that time, the 
System Kernel can check 536 whether the command buffer can be submitted forthwith (typically 
because no command buffer is Running). If not, the command buffer is left in the Waiting queue and 
10 a new command buffer must be obtained 534. Note that this functional block, which waits until a 
suitable Initialized command buffer is available and then allocates it to the device, is identical to the 
Q operation needed by Application 135 before it can begin drawing. 

When a Ready command buffer is selected for dispatch 540, System Kemel Support 530 - 
^ has the Kemel Driver 405 context switch the hardware to the appropriate context 551 and 
iyl5 dispatch the command buffer to the hardware 552. Hardware 306 then reads and executes the 

' command buffer 561 , until it is preempted or the command buffer finishes. If the command 
'^'^ buffer completes normally 563, the hardware signals an interrupt and the interrupt service routine 
i;3 553 executes. The ISR may wish to save the hardware context 554 at this time, although the 
S driver may wish to defer this operation to the context switch 55 1 , in case the hardware should be 
^ ^20 asked to execute two command buffers in a row that operate on the same context. After this step 
554, the Kemel System Support 530 can free the resources needed by that command buffer 538, 
as well as signal any notification mechanisms such as events to let interested clients know that 
the command buffer is completed. After step 538, the Kemel System Support has two distinct 
tasks: it must reinitialize the newly available command buffer and add it to the initialized pool 
25 533, and it must unblock any Waiting command buffers and move them into the Ready queue 
539. After step 539, another command buffer can be selected for dispatch 540. 

The complexity of the inter-process communications described with respect to Figures 4 
and 5 illustrate the need for managed code in accordance with an aspect of the invention. In 
particular, the system described with respect to Figure 5 could leverage managed code, in which 
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portions of the Application 135, Runtime 302, and/or User Mode Driver 303 are delivered in 
intermediate language form and JIT-compiled on the client. The three components would be 
delivered separately to the client in intermediate language form. The JIT compiler would then 
synthesize them into a unified piece of object code that included portions of all three 
components. Such an architecture should enable a system wherein more optimal object code 
would be executed. In addition, constants in the Application 135's call to an entry point could be 
propagated into the Runtime 302 and User Mode Driver 303, potentially resulting in object code 
that wrote a few constant words into the command buffer instead of crossing several function call 
boundaries in order to achieve the same result. The intermediate language form of the 
Apphcation 135 would still be hardware-independent, since the User Mode Driver 303 would be 
specific to the graphics hardware on the client. Moreover, all of the managed code could be 
delivered to the system over a network as described in Figure 1 above. 

While the best potential performance improvements should be achieved by generating 
managed code for all three components (i.e. Application 135, Runtime 302, and User Mode 
Driver 303), a system could have the Application 135 and Runtime 302 be managed and interact 
with a separate User Mode Driver 303, or even just Apphcation 135 be managed and interact 
with separate Runtime 302 and User Mode Driver 303. In fact, such subsystems could be made to 
coexist peacefully, provided the intermediate language and user mode DLL forms of the Runtime 
302 and/or User Mode Driver 303 were both available. 

The systems could also benefit firom late-bound managed code, much as has already been 
described. If the Runtime 302 was managed, a JIT could perform optimizations such as 
parameter validation checks at runtime. In the system of Figure 4, a unified piece of object code 
generated by the JIT would write canonical command buffer data into DMA-able memory for 
eventual submission to the hardware. In the system of Figure 5, the object code generated by the 
JIT would emit data into an intermediate buffer for parsing and translation by kemel mode driver 
405. The section below describes the system and advantages of the managed code aspects of the 
invention in further detail. 
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Managed Code 

The traditional mechanism for deployment of software has entailed writing source code, 
compiling the source code into executable form for a specific type of computer, and installing the 
executable code on the chent computer so it can be run. Another methodology, enabled in the .NET 
5 infrastructure, adds an extra step to this process. The source code is translated into a readily 
compilable, intermediate form that is installed on the client computer. The client computer then uses 
a JIT ("just in time") compiler to translate intermediate code into native executable "managed" code 
so it can be run. There are several advantages to this approach. One advantage is that the 
intermediate code is platform-independent; since the translation to executable code occurs on the 
10 client, any client that knows how to compile the intermediate code can execute the application. A 
related advantage is that the platform-independent intermediate code can be transmitted to and run 
Q on a platform that did not exist when the code was written. 

H In the context of the invention, however, the most important advantage of JIT compilation is 

that while the managed code is being generated, the JIT compiler has a priori knowledge of the exact 
hi 5 nature of the target computer (i.e., the client the JIT compiler is running on). If the client computer 

H S ii 

J' ' has a particular type of microprocessor, the JIT compiler can emit code that is native to that specific 

0 microprocessor. For example, the Pentium Pro microprocessor added conditional move instructions 
p to the x86 instruction set, and the Pentium 3 microprocessor added pre-fetch and other cache 
X management instructions that were not available on its predecessors. Supporting these 

1 y^O microprocessor-specific instructions in traditionally-deployed software requires the developer to 

write source code that uses all the various features, then write detection software to figure out which 
code path to execute on the client that the code happens to be running on. The JIT step frees the 
developer from this task and even proffers the developer protection against future innovations. In 
other words, a computer that included a new instruction that would benefit the developer's 
25 appUcation could include a JET compiler that knew how to emit that instruction; the application 
would benefit from the new instruction even if it did not exist when the application was developed. 
Proponents of online driver models cite performance advantages as the principal motivation for 
merging the API implementation into the driver. This merge has many undesirable side effects, 
mainly due to the inability of subsequent releases of the Runtime to add features, performance 
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improvements, or changes of API policy on top of drivers that predated the release of the Runtime. 
There is ample precedent in the history of DIRECTX that highlight the utility of API improvements 
that work on an installed base of drivers. These API improvements can range from easier-to-use 
drawing methods, such as the DIRECTX 5.0 DrawPrimitive API that worked on pre-DIRECTX 5.0 
drivers; performance improvements, such as the DIRECTX 6.0 geometry pipeline that worked on 
pre-DIRECTX 6.0 drivers; and API-level policy changes, such as the DIRECTX 6.0 texture manager 
that worked on pre-DIRECTX 6.0 drivers. These types of improvements are difficult or impossible 
to deliver if the drivers in question are online drivers. 

Just as the JIT compiler has a priori knowledge of the microprocessor type on the client, it 
also has a priori knowledge of the client's exact hardware configuration. In particular, it has 
knowledge of the type of graphics processor and the associated driver in the client. For example, at 
JIT time, the system knows the effective version of the graphics driver (DIRECTX 6.0, DIRECTX 
7.0, and so on), so if the application and driver are managed, the JIT compiler can emit an executable 
tuned for that driver version. Figure 6 depicts such a system. 

Application 135 and Runtime 302 are both received in an intermediate language form (IL) 
such as MICROSOFT'S CLRT. JIT compiler 602 takes Application IL 1 35 and Runtime IL 302 and 
merges them into a single compiled Managed Application 604. That application would 
communicate with Drive 303 and Hardware 306 as described above. 

The JIT-based approach depicted in Figure 6 enables many optimizations, including: 

- Support for different DDIs would be more efficient, since the DDI type is known at 
compile time. This eliminates large amounts of conditional code. 

- Conditional code can be eliminated if the condition is known at JIT time - e.g. 
parameter validation can be eliminated for guaranteed- valid parameters. 

- Trivial runtime functions can be inlined, enabling instruction scheduling around 
function calls. 

- The executable code (both inline and in the runtime implementation) could be 
targeted at the specific host processor type. The importance of processor-specific 
optimizations is increasing as microprocessor vendors increase the rate at which they 
modify instruction sets. 
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The performance of this architecture can be improved further by leveraging an intermediate 
language (IL)-based driver. 

Figure 7 provides an alternate embodiment of the managed code system. Here, the 
architecture would enable the compiled Application 135 to write hardware-specific commands 
directly into command buffers or FIFOs. Besides the performance implications, other potential 
benefits include reducing the engineering effort required for IHVs to deUver cross-platform drivers 
and better enabling validation tools to ensure the drivers' correctness. The Application 135, Runtime 
302, and Driver 303 are all delivered to JIT 602 in IL form. JIT 602 converts them into a Managed 
Application 604. 

Historically, DIRECTX has implemented a layered driver model in which the runtime 
translated graphics and drawing commands into a simplified, hardware-independent token stream. 
When the DIRECTX runtime determines that a flush was needed (i.e., the commands in the stream 
must be executed by the hardware), it would transition into kernel mode and pass the command 
stream to the graphics driver. The driver would then parse the conraiand stream and translate it into 
hardware-specific commands, and typically write those commands into a memory buffer for 
consumption by the hardware. 

Referring back to Figure 4 in conjunction with Figures 6 and 7, Kernel Mode driver 405 
would be of minimal size, implementing just enough code to initialize the hardware, initiate a DMA 
operation to consume an already-composed command buffer, and set up and handle interrupts. 
Implementing the invention in the context of Figure 4 could take two forms. First, as mentioned 
above, Application 135 and Runtime 302 could be compiled by JIT 602 so that late-bound managed 
code was interacting with Driver DLL 303. JIT 602 would then know the exact characteristics of 
Driver DLL 303 at compile time (for example, whether it implemented transform and lighting 
acceleration), and it could take advantage of that knowledge when generating object code for the 
client computer. 

The second, "managed driver" variant of the invention implemented in the context of Figure 
4 would entail having Application 135, Runtime 302, and Driver DLL 303 all compiled by JIT 602, 
so that a unified piece of executable code was performing the translation from API and writing 
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hardware-specific commands into DMA memory 41 0. This architecture combines the robustness and 
other advantages of a layered driver model with the efficiency gained by the hardware specificity of 
an online driver model. Hence, this "managed driver model" proffers a higher potential for 
performance compared to other driver architectures. 

As mentioned above, while exemplary embodiments of the present invention have been 
described in connection with various computing devices and network architectures, the 
underlying concepts may be appUed to any computing device or system in which it is desirable to 
manage applications and drivers. Thus, the techniques for managing applications in accordance 
with the present invention may be apphed to a variety of applications and devices. For instance, 
the advantages of the invention maybe applied to the graphics system of a computing device, 
provided as a separate object on the device, as part of another object, as a downloadable object 
from a server, as a "middle man" between a device or object and the network, etc. The managed 
application generated may be stored for later use, or output to another independent, dependent or^ 
related process or service. While exemplary programming languages, names and examples are 
chosen herein as representative of various choices, these languages, names and examples are not 
intended to be limiting. 

The various techniques described herein may be implemented in connection with 
hardware or software or, where appropriate, with a combination of both. Thus, the methods and 
apparatus of the present invention, or certain aspects or portions thereof, may take the form of 
program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD- 
ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program 
code is loaded into and executed by a machine, such as a computer, the machine becomes an 
apparatus for practicing the invention. In the case of program code execution on programmable 
computers, the computing device will generally include a processor, a storage medium readable 
by the processor (including volatile and non-volatile memory and/or storage elements), at least 
one input device, and at least one output device. One or more programs that may utilize the 
boimdary discovery techniques of the present invention, e.g., through the use of a data processing 
API or the Uke, are preferably implemented in a high level procedural or object oriented 
programming language to communicate with a computer system. However, the program(s) can 
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be implemented in assembly or machine language, if desired. In any case, the language may be a 
compiled or interpreted language, and combined with hardware implementations. 

The methods and apparatus of the present invention may also be practiced via 
communications embodied in the form of program code that is transmitted over some 
5 transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any 
other form of transmission, wherein, when the program code is received and loaded into and 
executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a 
client computer, a video recorder or the like, or a receiving machine having driver techniques as 
described in exemplary embodiments above becomes an apparatus for practicing the invention. 
10 When implemented on a general-purpose processor, the progr^ code combines with the 

processor to provide a unique apparatus that operates to invoke the functionality of the present 
P invention. Additionally, any storage techniques used in connection with the present invention 

may invariably be a combination of hardware and software. 
^0 While the present invention has been described in connection with the preferred 

I yl 5 embodiments of the various figures, it is to be understood that other similar embodiments may be 
" used or modifications and additions may be made to the described embodiment for performing 

the same function of the present invention without deviating therefi-om. For example, while 
□ exemplary network environments of the invention are described in the context of a networked 
pi environment, such as a peer to peer networked environment, one skilled in the art will recognize 
^M20 that the present invention is not limited thereto, and that the methods, as described in the present 
apphcation may apply to any computing device or environment, such as a gaming console, 
handheld computer, portable computer, etc., whether wired or wireless, and may be applied to 
any number of such computing devices connected via a communications network, and interacting 
across the network. 

25 Furthermore, it should be emphasized that a variety of computer platforms, including 

handheld device operating systems and other application specific operating systems are 
contemplated, especially as the number of wireless networked devices continues to proliferate. 
Still further, the present invention may be implemented in or across a plurality of processing 
chips or devices, and storage may similarly be effected across a plurality of devices. Therefore, 
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1. A computer system, comprising: 
a processor; 

an operating system having a selected driver that interacts with a computing component; 

a plurahty of application instructions, said instructions being in an intermediate language 
readable by an intermediate language compiler; 

a plurality of runtime instructions, said instructions being in an intermediate language 
readable by an intermediate language compiler; and 

an intermediate language compiler wherein said intermediate language compiler compiles 
the application instructions and the runtime instructions into instructions executable by the 
processor for interacting with the selected driver. 

2. The computer system as recited in claim 1 wherein the selected driver comprises a plurality of 
intermediate language instructions. 

3 . The computer system as recited in claim 2 wherein the selected driver is split into user mode and 
kemel mode instructions. 

4. The computer system as recited in claim 3 wherein the user mode instructions of the selected 
driver translates from device driver interface instructions to hardware-specific commands. 

5. The computer system as recited in claim 4 wherein the selected driver writes hardware-specific 
commands into an operating system-allocated buffer for submission to a scheduler of the hardware's 
time. 

6. The computer system as recited in claim 1 wherein the plurahty of application instructions and the 
plurality of runtime instructions are delivered to the computer system over a network. 



